Posted by marvin from l316t1p28.netway.at (195.96.17.156)on March 23, 1998 at 05:55:50:
This is a LONG one - the story of RRedline Croc(tm)....(Part I?)
I was ill the last few days (probably some bad Voodoo magics??? 8-B)
and at home I did not have the password to the developer section,
however on Sunday I was up again and was very busy working on
the Croc driver - with success, as it seems!
1) Disclaimer
Let me explain some things first: my Croc driver is an offspring
of an early version of BigRRed - my reasoning behind it was
the following:
o) I want to play Croc - I was annoyed that Croc was supporting
only Glide, ATI, Mystique(!) and Virge(!) with HardwareAccelaration.
o) I suspected that Croc, by supporting this different set of
hardware, would not use very Glide-exclusive function -
this has turned out to be right!!!
o) I think the choice of Croc is justified by the fact, that it
is one of the (fortunately) few Games for which a Glide but
not a D3D version exists....- here a Glide-wrapper (oops)
makes really sense, even it is somehow slow....
o) When I made the logging DLL and saw how few Glide functions are called,
I started the actual work...
o) I tried to minimize work and to concentrate on making a Game-driver
that does support only the needed functions, not the higher Glide-
functions that may be called only by some very sophisticated
glide games.... Therefore there was no problem in starting
with an intermediate version of BigRRed, since the development
of BigRRed has recently led into another direction - more on
this below...
o) So, to sum it up, I see the Croc driver as a specialized offspring
of BigRRed, where some techniques have been realized that now can
be incorporated back into BigRRed (see below).
Let me talk of another problem right now: I don't know how to call
the thing in the public. I am inclined to a proposal once made by someone
here on the webboard (can't remember who it was), to call such a
thing simply a "gamedriver for XXXX" (in this case Croc), in order to
avoid any legal problems... I am living happily in Austria, I have
no real enemies right now (at least I hope so), and I have
a family to feed, so am NOT really interested in a lawsuit by
3dfx .... ;-). So I don't want to have anybody mention this nasty
term "Glide-Wrapper" in the context of my driver...;->
I don't really dare to call it BigRRed since it is
only an offspring of it, and since BigRRed will call Voodooists on
the plan, am I right? Sidenote: on the other hand, by being derived
from BigRRed, I think my driver is also, somehow, Jeff_C's baby -
so if he would like to call it - in line with his developments -
BigRRed (Special Croc-Edition), I will welcome it.
I am also indebted to Chris Lundie, who helped me with his
comments and tips....Thanks a lot, Chris!
However, for me BigRRed is a much bigger project, and the small
offspring of this game driver is only a testing balloon for the
whole project, giving back (hopefully) some new insights and
techniques to the main project...
My own working title for this driver was "Scarlet", but I don't
think it is a good one...
Perhaps Bjorn or someone else could suggest how we will call the
thing, and how we will distribute it....
2) Status of the driver (non-technical):
After about 3 full days of work (summing my hours together...) I now
have almost finished the driver (to me a sort of specialized
mini-Gl(ide)-Wrapper), and everything in Croc runs great, looks great
and has decent performance!!! There are only some visual glitches
left (some blending modes and a problem with turning chromakeying off
at the right time) - all glide modes have a direct rendition equivalent,
so speed is not much compromised (the wrapping(oops)layer is very
thin...) and there is still some room for optimizations...
One problem I still have, though, is stability: firstly, after some specific
levels, a few textures are trashed, and secondly, at some other specific
levels and at starting the long intro sequence (which you can select
in the main game menu) Croc crashes... Since these errors are
at least fully reproducible, I am in hope to find these bugs (though
debugging is of course, very difficult).
On the brighter side, many levels play without any problem and look
awesome!!!! So if it weren't for these stability problems, I almost
would call this driver 95% finished!!!! (only the blitting function
grLfbWriteRegion (or so) needs to be implemented (no problem) for
the first static intro picture...). I was really surprised how easy
everything so far was! To all Voodooists: to me, the RRedline SDK is in
(almost) no way more difficult to handle than Glide SDK! Baeh!
(I remember many people arguing on the net that Glide is the most
easy SDK, and was therefore chosen by the game companies...).
A word of caution: of course the Croc driver is in effect a
glide-rredline wrapper, but it really supports only the
subset of calls Croc developers have chosen to use... I doubt
that any other game uses exactly the same subset...
For example, there are some different Glide functions that serve
almost the same purpose. If Croc used only one of these
functions I supported only this one....
What I want to say? Well, from its basic functionality (texture
management, color modes, etc...) the wrapper is already
very advanced, but the interface is not yet extended but
is kept very specialized for Croc.... I now believe a universal
wrapper IS possible, and is not very far away, and will be
quite fast....
3) Testing
I don't have a 3dfx card, so I would really be interested in
people having both a 3dfx and a Rendition 2x00 card, and Croc.
I hope, at least Bjorn qualifies for this? I would be very
interested in a direct comparison of visual appearance and
performance between Glide and Glide-RRedline!!!
Some screenshots of the game would also be nice: perhaps someone
can point me to a screenshot utilty for RRedline games?
Or will Bjorn be so nice to make them :-)))?
Of course everyone owning Croc and a Rendition card can test
the driver (in this early state) if she/he likes... V1000 owners
may have performance problems (I have given my 3DBlaster away,
and am developing on a 8MB Thriller, however powered only with
a P133), since the game uses Z-Buffering...
I am waiting for some response or suggestion from Bjorn, then
I will immediately release this version of the driver.
4) Status and features of the driver (technical)
I took an early version of BigRRed - when the BigRRed35 source
was released, I browsed through it, merged some details from it,
but did NOT merge the new drawing primitives into my driver,
since Croc only uses grDrawTriangle()!!
By modifying the existing code, adding chunks of own code,
and merging some Rendition code into the driver, I enhanced
BigRRed mainly with the following functions:
o) Logging:
Logging from the logging-dll version is still included,
now with more detailed warnings about modes and parameters
that are currently not supported - should suffice to
quickly tell whether a game will be easily portable.
o) Z Buffering:
Z buffering was almost done in BigRRed, I only changed some
details (clearing, modes,Z-coordinate calculation)...
o) Dynamic Vertex types
When it came to texture mapping, new vertex types were needed -
I finally decided to use 4 different vertex-types dynamically,
depending on color, alpha and texture modes. This is transparent
to the drawing routines like grDrawTriangle()....
Most of the 'work' is done in a routine (heavily) derived from
the initial ConvertGlToR() routine....
All coordinate and parameter conversions now seem to work, for
u and v parameters some additional tricks are needed, since
glide textures have strange coordinates, depending on their
aspect ratio. So u, v have to be conditionally scaled depending
on the current texture...
Perspective correction seems to work without any problem...!
I only experienced a strange problem, where the use of the
simple V_XYZ vertex leads to a lock at SwapBuffers (even
at the glide example 00)....
Can't explain why, currently I simply don't use this minimal
vertex type....Strange, though.....
o) In-Window routines
One of the first things I tried was incorporating the code
from HTRI2 for windowed rendering. It somehow worked, but it
still needs work. I haven't done everything yet, and I decided
that other things have higher priority. However, soon I want
to try to finish this work.... The most and most difficult
work seems to me to have nice initialization and restore routines
for the case when the application is minimized and almost
everything in Verite's gut is lost and forgotten....
Perhaps I will never allow to minimize the application!
o) Texture Management
This is one of the biggest points and a true winner. The fact
is, it was not that difficult as it seemed at first (though
I strongly suspect that the instabilities of the driver are
related to this management routines....- so I don't want to
take my mouth too full too soon ;-)
Since every Glide program that does not use the guAllocate...
helper functions has to implement its own texture allocation
algorithm, I decided that they should manage the Rendition
texture cache (almost) by themselve... Using ideas from
the chapter on optimizations in the RRedline manual, and
from the frame example program (horrible complicated!), I
implemented texture management in the following way (it
is currently limited to the formats RGB_565 and ARGB_4444,
which don't need any conversion at all - very practical
MipMaps are supported only in that way that simply the
first (largest) Map is taken as texture, the smaller mip
maps are ignored)
o) in the OpenWindow routine, I allocate the remaining
Rendition memory as one large texture cache
o) for the application, I convert, calculate and give back
rendition addresses and memory sizes for the functions
TexMinAddress, TexMaxAddress, TexCalcMemRequired and
TexMemRequired... - as a result, the application
manages the memory by itself (if you have an 8MB card,
the whole memory should be automatically used!)
o) on DownloadMipMap, I lock the original source (could
be optimized and enhanced for format conversions...)
and create a new entry in my texture allocation table,
and create a new surface for this texture as part
of the texture cache with a call to VL_PointSurface()
(very important function!).
My texture allocation table is a table of all currently loaded
textures and is mainly needed to solve one problem: the
rendition surfaces, which have been created for each texture
load, have to be freed - glide will never tell you when....
So I have to detect on each new texture load, whether it overwrites
some textures in memory - if it does, these textures can
be freed.... This is all done automatically now, and it seems
to work great....
I have one strange 'problem', which seems like a programming
error of Croc to me: there is a set of guTex...() helper
functions for a higher level texture interface, which Croc
fortunately does not use - it provides memory management
(would have to implemented then...), returning handles to
allocated mip maps (mipmap_id). The glide documentation
clearly and reasonably states that you can't mix both types
of texture management - however, Croc sometimes calls not
grTexSource but guTexSource, with a mipmap_id of -1 (ffff).
I don't know what this means...
Aeh, before I forget to mention it: bilinear filtering and
texture clamping/wrapping is of course fully supported...
o) Color,Alpha,Blend modes (and Chromakeying)
This part is tricky and I did only the very small subset which
is needed for Croc - I still have some open problems here...
Basically you must find a tricky mapping between the glide
parametes set by grColocCombine, grAlphaCombine, and grBlendFunction
and the renditon SrcFunc, BlendEnable, BlendSrc and BlendDst
functions...At this point the ConstantColor and vertex types
play their role, too.... Probably almost every abstruse
Glide combination could be mapped to some tricky settings
on the verite... However, this IS tricky...
Currently, I simply try to identify the more abstract,
most common color and texture map modes like FlatShading,
GouraudShading,ReplaceTexture,FlatTexture
and GouraudTexture and the most simple alpha blending mode...
For Croc, this almost works for almost all cases...
There also exists some higher level functions in Glide
(e.g. guColorCombineFunc) that facilitate this view....
Chromakeying was the last feature I implemented and it
gives some headaches: on the rendition, it can only work
with some special texture modes, since the alpha value
is used in the chromakeying process.. There may occur
some nasty interferences between the different modes....
Interestingly, the biggest problem for me with chromakeying
was NOT putting it to work (worked almost instantly!) but
to figure out how to automatically switch it off,
since Croc does not instantly and explicitely turn it off,
and so suddenly many surfaces disappeared randomly....
Perhaps I still do not understand when Glide uses
chromakeying and when not.....
5) Croc driver and BigRRed, the future
I know that I am guilty of having not sticked to BigRRed development
discipline and of having pursued my own path...
As an excuse, I must say, that this is only my spare time project,
and I wanted to work with fun and most efficiently, and therefore I
wanted to do some things in exactly the way as I want them to do....
Furthermore
However, surely I want to support BigRRed and want to make it as
BIG as possible, and I think with the Croc driver I added many
things that have been missing till now....
I now want to offer my help in the process of bringing the things
I have developed back into the original framework of BigRRed...
From my perspective, I did not change much, and simply added some
new things.... In this respect, a merge should be not much problem...
The only thing we have to be careful at are some small changes
I had to make to the redline_xxxx functions to suit my needs -
changes that are very small, so that may be easily overlooked....
Then there are some architectural decisions which I did and which
should be discussed...(when to set color modes, when to install
the textures, etc...)
Perhaps Jeff_C can contact me and we can discuss how to merge
happily.... Though my code obviously contains still some bugs
that prevent Croc from running stable, I could immediately make
my sources public, could add some explainations to it, and then
we can decide what and how we merge......
I am also planning to make a fully commented list of all
glide functions, divided into the categories: fully supported,
partly supported (what is missing), not yet supported (what is
neede?, how much work?, how important), and never supported
(utterly useless or absolutely impossible...)....
Have a nice day, folks
and thanks again to Jeff_C and Chris Lundie...
marvin
P.S: please forgive me, almighty Voodoo, for I have sinned....
(and it was fun... ;-b)